MCP Interview Notes

1. What problem does MCP actually solve, and why couldn't we just keep using regular function calling or plain REST API integrations with LLMs?
2. Walk through the architecture: the host, the client and the server, and how they relate. When a tool is "exposed" by a server, what does that mean under the hood?
3. In an agentic system, when the LLM decides to call a tool through MCP, who actually makes that decision, and what role does the server play versus the model?
4. What transport mechanisms does MCP use to move messages between client and server, and when would you pick one over the other?
5. What is the difference between stdio and HTTP+SSE, and what is the decision rule for a local versus a remote server?
6. What are the three primitives an MCP server can expose (tools, resources, prompts), and who controls each one?
7. Walk through the lifecycle of an MCP connection: handshake, capability negotiation, discovery, execution, shutdown. What does each side learn about the other during initialization?
8. What are the main security risks in MCP (prompt injection, tool poisoning, over-privileged servers, confused deputy), and how would you design guardrails?
9. You are an architect at a bank with about 20 internal systems. How would you structure the MCP servers, and where would you put authentication, authorization, audit logging and rate limiting? How would you handle tool sprawl in the model's context?
10. How does MCP compare with plain function calling, REST APIs and agent-to-agent protocols like A2A? When would you choose MCP, and when would it be the wrong choice?

Question: What problem does MCP actually solve, and why couldn't we just keep using regular function calling or plain REST API integrations with LLMs?

Answer: Without MCP, every AI application needs custom glue code for every tool. With M applications and N tools, that is M×N integrations, and a change on either side breaks that pairing. MCP is one standard protocol: each tool exposes one MCP server, and each application implements one MCP client. The effort drops from M×N to M+N.

• Each tool still has its own server. What becomes "one" is the protocol, not the server count.
• Write the client logic once against the spec, and it works with every compliant server.

Say it in one line: "MCP collapses M×N custom integrations into M+N by standardizing both sides."

Question: Walk through the architecture: the host, the client and the server, and how they relate. When a tool is "exposed" by a server, what does that mean under the hood?

Answer: There are three layers.

• Host: the application the user sees, such as Claude Desktop, an IDE or a custom agent app.
• MCP client: lives inside the host. There is one client instance per server, each holding a dedicated one-to-one, stateful connection. Five tools means five clients. The client handles the handshake, discovery and message passing.
• MCP server: a lightweight program wrapping a capability. It can run locally as a subprocess or remotely over the network. It exposes tools, resources and prompts.

Every message between client and server is JSON-RPC, carried over stdio (local) or HTTP (remote).

What "exposed" means: the client makes a discovery call (list tools), and the server replies with a JSON schema per tool: name, description and input parameters. The host puts those schemas into the LLM's context so the model knows what it can call.

Say it in one line: "The host contains one client per server, they speak JSON-RPC, and exposing a tool means publishing its schema through discovery."

Question: In an agentic system, when the LLM decides to call a tool through MCP, who actually makes that decision, and what role does the server play versus the model?

Answer: The LLM decides. Discovery has already happened, so the tool schemas are in the model's context. The model reasons over the user's request and the available tools, then outputs a structured message: "call this tool with these arguments." It executes nothing itself.

1. The host and client catch that output, validate it against the schema and route it as a JSON-RPC request to the right server.
2. The server does the real work, because it holds the credentials: it hits the database or API and returns the result.
3. The result goes back into the model's context, and the model decides whether it is done or needs another call.

It is a loop: the model proposes, the infrastructure executes, the result returns, the model reasons again.

Say it in one line: "The model decides what and when; the server executes. The model has no hands, the server has no judgment."

Question: What transport mechanisms does MCP use to move messages between client and server, and when would you pick one over the other?

Answer: Every MCP message is JSON-RPC, which is the message format, like an envelope. The transport is how the envelope travels. There are two.

• stdio: the server runs locally as a subprocess of the host. The client writes JSON-RPC to the process's standard input and reads responses from standard output. No network, very fast.
• HTTP with Server-Sent Events (SSE): the server is remote. The client sends requests as HTTP POST, and the server streams responses back over SSE. Newer versions of the spec call this "streamable HTTP," a more unified version of the same idea.

It is not gRPC and not plain HTTPS alone. Say "stdio" and "HTTP with SSE" specifically.

Say it in one line: "JSON-RPC is the message format; stdio is the transport for local servers and HTTP with SSE for remote ones."

Question: What is the difference between stdio and HTTP+SSE, and what is the decision rule for a local versus a remote server?

Answer: The deciding factor is locality and who controls the server's lifecycle.

	stdio	HTTP + SSE (streamable HTTP)
Server runs	Locally, as a subprocess of the host	Remotely, on another machine or a SaaS endpoint
How messages travel	Standard input and output pipes	HTTP POST for requests, SSE for streamed responses
Network needed	No	Yes
Typical use	Local file system or local database tool	A vendor's hosted MCP endpoint, a shared internal server

Keep two ideas separate: stdio is the transport, and JSON-RPC is the message format that runs over either transport.

Say it in one line: "Same machine and lifecycle tied to the host: stdio. Different machine or a service I don't control: HTTP with SSE."

Question: What are the three primitives an MCP server can expose (tools, resources, prompts), and who controls each one?

Answer:

Primitive	What it is	Who controls it	Example
Tool	An action the model invokes to do or compute something	The model	get_account_balance, send_email
Resource	Data to read, with no arguments or action	The application or user attaches it to context	A README, a log file, a database record
Prompt	A reusable, well-crafted prompt template the server ships	The user triggers it, often via a slash command	"Review this pull request for security issues"

Why three? Tools let the model act. Resources supply context without the model going to fetch it. Prompts give users structured workflows.

Say it in one line: "Tools are for the model to act, resources are for the application to supply context, and prompts are for the user to trigger workflows."

Question: Walk through the lifecycle of an MCP connection: handshake, capability negotiation, discovery, execution, shutdown. What does each side learn about the other during initialization?

Answer: Four phases, in this order.

1. Initialization and capability negotiation: the client sends an "initialize" request with its protocol version and capabilities. The server replies with its own protocol version and capabilities (tools, resources, prompts, notifications, sampling). Both sides now know what is usable in this session. The client then sends an "initialized" notification.
2. Discovery: the client calls list tools, list resources and list prompts. The server returns names, descriptions and input schemas, which the host feeds to the LLM.
3. Operation: the model decides, the client sends a "call tool" request, and the server executes and returns a result or an error. Resources are fetched with read-resource calls. Servers can send notifications, for example when the tool list changes.
4. Shutdown: the client closes the connection. For stdio that means terminating the subprocess; for HTTP it means closing the connection cleanly.

Mention the handshake first, unprompted. Capability negotiation is what makes the protocol extensible: new features can be added without breaking older clients or servers, because each side declares what it understands up front.

Say it in one line: "Handshake and capability negotiation, then discovery, then operation, then shutdown."

Question: What are the main security risks in MCP (prompt injection, tool poisoning, over-privileged servers, confused deputy), and how would you design guardrails?

Answer: The model decides what to call, but the server holds real, privileged access. All the risks live in that gap.

Risk	What happens
Prompt injection	Untrusted content (an uploaded document, an email) carries hidden instructions like "transfer funds", and the model cannot reliably separate data from instructions.
Tool poisoning	A malicious or compromised server describes a tool innocently but does something harmful, or changes its description after being trusted (a "rug pull").
Over-privileged servers	One server with full read-write database access, when the agent only needs balances, gives any bug or bad prompt a huge blast radius.
Confused deputy	The server acts with its own credentials on the model's request and does something the real end user was never authorized to do. The chain back to the human is broken.

Guardrails:

1. Least privilege: narrow, purpose-built servers (a read-only balance lookup, not arbitrary SQL).
2. OAuth with scoped, short-lived tokens for remote servers, carrying the real user's identity through instead of static API keys.
3. Human approval for sensitive or irreversible actions such as money movement or KYC changes.
4. Audit logging of every tool call, its arguments and its result, tied to the user session.
5. Treat tool outputs as untrusted: validate them before they influence the next call.

Say it in one line: "For a bank I lead with confused deputy and human approval for money movement."

Question: You are an architect at a bank with about 20 internal systems. How would you structure the MCP servers, and where would you put authentication, authorization, audit logging and rate limiting? How would you handle tool sprawl in the model's context?

Answer:

        User
         | 1. asks question
         v
+-------------------+
|   Host (LLM +     |
|   MCP client)     |
+---------+---------+
          | 2. call + user token
          v
+-------------------+
|    MCP GATEWAY    |
| 3. AuthN (OAuth)  |
| 4. Rate limit     |
| 5. Audit log      |
| 6. Intent router  |
+-+-----+-----+---+-+
  | 7. load only the matching domain
  v     v     v   v
+----++-----++---++-----+
| MF ||Demat|| Ins||Loans|
| MCP|| MCP || MCP|| MCP |
+-+--++--+--++-+--++--+--+
  | 8. AuthZ per account / row
  v      v     v    v
+-----------------------+
| Core systems (the 20) |
+-----------------------+

• Grouping: one MCP server per domain (mutual funds, demat, insurance, loans), not per system and not one giant server. Each domain team owns and deploys its server, like microservice boundaries.
• Authentication: the gateway validates OAuth tokens scoped per user session, so every call carries the real end user's identity and not a shared service account. This also addresses confused deputy.
• Authorization: each server enforces account-level and row-level checks itself and never trusts the model's intent.
• Audit logging: centralized at the gateway, recording every call, its arguments, the resolved user and the result, correlated by session ID.
• Rate limiting: at the gateway per user and per tool, plus per-server limits as a second layer, so a runaway agent loop cannot hammer core systems.
• Tool sprawl: 20 systems with 5 to 10 tools each means 100+ schemas in context. Use an intent router to load only the matching domain's tools per turn, and prefer fewer, coarser tools ("get portfolio summary" instead of five CRUD calls).

Say it in one line: "Draw MCP boundaries by domain, not by system, and solve tool sprawl with routing, not by dumping everything into context."

Question: How does MCP compare with plain function calling, REST APIs and agent-to-agent protocols like A2A? When would you choose MCP, and when would it be the wrong choice?

Answer: They sit at different layers, so they complement each other more than they compete.

Option	What it is	How it relates to MCP
Function calling	A model-level feature: the LLM emits a structured call for a function you define in your own app code	Defines how the model asks for a call. MCP standardizes where the tools live and how any app discovers and invokes them. An MCP host usually still uses function calling underneath.
REST API	A service interface designed for developers and fixed integrations	MCP servers often wrap REST APIs, adding self-describing schemas, discovery and a uniform protocol so an agent can use them without custom glue.
A2A (agent-to-agent)	A protocol for agents to discover and delegate tasks to other agents	MCP connects an agent to tools and data; A2A connects an agent to other agents. They are used together.

Choose MCP when:

• Several AI applications need the same tools, so you want to write the integration once (the M+N argument from Q1).
• You want dynamic discovery of tools and clear control boundaries for auth, audit and approval.
• Tools should be owned and versioned by the teams that own the systems.

It may be the wrong choice when:

• You have one app with a handful of fixed tools, where plain function calling is simpler and has less overhead.
• A deterministic pipeline or a direct REST call is enough and no model needs to choose tools at runtime.
• Latency or throughput is critical and the extra protocol hop and tool-schema context cost are not justified.

Say it in one line: "Function calling is how the model asks, MCP is how tools are standardized and discovered, REST is what the tools often wrap, and A2A is how agents talk to each other."